1. Field of the Invention
The present invention relates to a method for optimizing network performances, wherein the network comprises one or more network nodes, performance parameters of said network nodes being controlled by means of dedicated optimization modules, wherein each optimization module monitors at least one performance parameter of the network node to which said optimization module is associated and generates a change request for the current value of said performance parameter on the basis of preset rules.
Furthermore, the present invention relates to a system for optimizing network performances, the system comprising dedicated optimization modules for controlling performance parameters of network nodes of the network, wherein each optimization module is configured to monitor at least one performance parameter of the network node to which said optimization module is associated and to generate change requests for the current value of said performance parameter on the basis of preset rules.
2. Description of the Related Art
The maintenance of a network involves a continuous process, where some performance data is analyzed and some configuration parameters are changed to maintain or optimize network performances. This is normally called “optimization process” of a network.
An optimization process in current networks is normally very specialized, i.e. there is a specific function module which is referred to as optimization module and which is delegated to optimize a specific performance parameter. From a black-box perspective, an optimization module reads the performance data and generates the new configuration for the network. The decision is based on goals enforced by the network administrator and by some additional constraints (“contour conditions”). Such optimization process is illustrated in FIG. 1.
As an example of a performance parameter to be monitored on a network node one can think of the average load or the average number of service requests rejected (e.g. telephone calls or network connections). In the latter case the number of service requests rejected would be continuously monitored and if the number exceeds certain thresholds (e.g. more than 10 requests rejected per hour), the optimization process would be started. In the case of a wireless network, in order to regulate the distribution of load between base stations, the power of the “pilot channel” of the base stations is normally tuned in: the higher the power, the bigger the area covered and the higher the average load received by the base station. Therefore, if a base station has too much load, with respect to predefined goal values, the optimization process would try to decrease the power of the pilot channel provided that some contour conditions are respected (e.g. a condition may require full coverage area).
Currently, in operative networks optimization processes as described above are executed on a central management station, which sends new configuration parameters to the managed network nodes. Moreover, normally the optimization process is performed manually by a person, e.g. the network administrator, who sends the configuration values. As for the example described above, it is likely that the values for the powers of the pilot channels of the base stations are configured manually, only after some alarms are reported to the administrator. For instance, in case certain preset thresholds on the load are overcome, an alarm is reported to a management station and the administrator is in charge to define a new value for the power of the pilot channel. This method, which is illustrated together with the related data flow in FIG. 2, is clearly time-consuming, error-prone and not efficient.
However, some degree of automation is sometimes adopted through the use of some scripts, which is also illustrated in FIG. 2. For example, a script can automatically change the value of a performance parameter of a network node, e.g. the power of the pilot channel of a base station of cellular communication network. Anyway, this is normally applied only on limited cases, because the execution of these scripts requires a proper design and dedicated computational resources. Moreover, since they are executed on a single central management station, this automated method does not scale for large networks.
Recently emerging network architectures will try to use self-organizing principles as much as possible: the optimization processes will be automated and delegated to the managed network nodes as much as possible and different modules (e.g. programs implementing specific optimizing algorithms) will be executed locally to change many parameters. It is expected that each module will be designed for a specific function and will control a specific domain of the configuration parameters. Nodes can collaborate with each other, by exchanging information and/or commands. The advantages of such architecture are scalability, prompt intervention and reduced need of manual intervention. An example of such self-optimizing network architecture is shown in FIG. 3.
One of the problems of this approach is the coordination of the different optimization processes within the same network node and between different nodes. The problem is that the self-optimizing modules are designed and implemented independently. As a consequence, each module is not aware of the presence or the functions of the other one. The reasons for this are both technical and practical. Technically the design of a standalone optimizing algorithm and module is much easier than a combined problem. Practically each module is designed as answer to different problems and therefore the different modules are put together in the late integration stage of a product development, or even worse during the deployment of the network.
An exemplary use case for self-optimizing nodes in the evolved UTRAN is the adaptation of the cell coverage of the cells, depending on the working conditions of the neighboring cells. More in detail, if a cell is not working or is switched off for energy saving purposes (e.g. over night), its neighboring cells should increase their own coverage areas to maintain full coverage over the previous area. The coverage area is adapted by changing the power of the pilot channel of the cell. The problem is that the power of the pilot channel is also controlled by a load balancing mechanism. The concurrent access of two self-optimizing mechanisms to the same performance parameter can lead to unwanted effects, like a high frequency of changes of a parameter (e.g. power of the pilot channel changing several timers per minute) or oscillations of a parameter (e.g. a power of the pilot channel oscillating between two high and low values).
To solve these problems, it has already been proposed to implement additional logic inside each module to coordinate the interactions with other modules. The drawback of such an approach is however that it results in several points of attachment for the input of operator's policies and that it certainly requires additional complexity and adds additional costs. Moreover, this approach is not general for any additional module: when a new optimization module is introduced in the network entity and it interferes with an existing module, the existing module must be implemented again to take in account the interferences of the new module. At the end one would have “heavy modules” and eventually the costs for the required synchronization logic on each module may compensate the benefits of the automation introduced.
To summarize, the new architectures with local automated optimization processes will have the problem of concurrent configuration changes with respect to three aspects: First, concurrent change requests on the same configuration parameters coming from different modules. For example, a load balancing module and a cell outage module can concurrently change the power of the pilot channel. The problem is evident when the concurrent modules want to enforce opposite values (e.g. one modules increases and the other decreases the value). Secondly, concurrent change requests coming from different nodes, and, thirdly, repeated change requests on the same configuration parameter. For example the change requests could occur too often and some requests should be filtered. This effect is clearly more evident when different modules are involved. The side effects of these concurrent changes are unwanted configurations (i.e. bad values) or unwanted dynamics (e.g. too frequent changes) of the configuration of the node.